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(57) In a multiprotocol environment, a new socket 
structure is provided which moves the decision 
on which protocol to use until the time that the 
connection is actually made between nodes in 
the network. The new socket structure is 
created for every end point All the protocols 
which could potentially be used to send or 
receive data is sent a request to create a pro- 
tocol control block at the time the new socket is 
created. A selection process determines which 
of the protocols could be used by the endpoint 
The new socket then contains information on 
each selected protocol. At the time a connec- 
tion is established, any of the selected protocols 
could be used. The choice of which protocol to 
use can be based on user preferences, which 
protocols are available, the name of the service 
unit 
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BACKGROUND OF THE INVENTION 

This invention relates generally to data communication in a network of computer systems. More particu- 
larly, it relates to a communication endpoint structure which enables application programs resident on systems 
5 to communicate through such a network irrespective of the protocol for which the application was written and 
the protocols available on the network. 

Once upon a time, almost all computer systems were standalone processors to which private peripheral 
devices such as displays, printers and disk drives were connected, acting independently from any other com- 
puter system. Yet, it became apparent: that there were substantial gains to be made if several computer sys- 
10 terns could be cooperatively coupled together. Today, it has become commonplace to couple a multitude of 
computer systems into a distributed environment such as a local area or wide area network. 

However, there are many vendors who have developed their own hardware and software solutions for in- 
tegrating multiple computer systems. In particular, they have developed different ideas of the format and pro- 
tocols that should be followed in transporting data through the networks. Some protocols support expedited 
15 data transmission by bypassing the standard data flow controls; others require all data to go through the con- 
trols. Specialized protocols are used for transport tasks such as establishing and terminating connections be- 
tween computer systems. Examples of well known communication protocols include System Network Archi- 
tecture (SNA), Digital Network Architecture (DECnet), Transmission Control Protocol/Internet Protocol 
(TCP/IP), Network Basic Input/Output System (NetBIOS), Open Systems Interconnection (OSI) and AppleTalk. 

20 Other protocols are known and widely used. 

Most distributed application programs are written to an application programming interface (API) which as- 
sumes a particular communications protocol. However, the distributed environments which most organizations 
have assembled are quite complex, comprised of confederations of individual networks running different com- 
munication protocols. If the transport protocols assumed by the distributed application's API and the transport 

25 protocols actually implemented in one or more of the networks on which the organization would like to send 
its data are not the same, the use of the application is limited. The problems of such heterogeneity in commu- 
nications protocols is expected to get worse as more organizations begin to communicate with each other 
through their networks to perform order processing, direct billing or other cross organization activities. 

While the distributed applications could be rewritten so that they can run over each transport protocol or 

30 application gateways can be written for each distributed set of distributed applications, the cost of having pro- 
grammers write all the necessary code makes these approaches economically unattractive. A preferred solu- 
tion is presented in copending application, Serial No. 731,564, entitled "Compensation for Mismatched Trans- 
port Protocols in a Data Communications Network", by R.F. Bird et al, filed July 17, 1991 and hereby incorpo- 
rated by reference. The incorporated application teaches a transport connection layer between a first transport 

35 user at one node in the network and a second transport user at a different node in the network. When the 
transport protocol assumed by the application at the first node is not available in the network, the data being 
transferred between the two nodes is automatically altered to be compatible with the available transport pro- 
tocols. Thus, an organization is able to choose application programs solely on the basis of the functions they 
provide, rather than the protocols which they require. 

40 The above referenced application teaches a generalized transport layer. One of the transport structures 

which is presently used in the Berkeley version of the UNIX(TM)environment is called a socket. A socket is an 
object that identifies a communication endpoint in a network. A socket hides the protocol of the network ar- 
chitecture beneath from the application. A socket allows the association of an endpoint, such as an application 
program, with one of the selected protocols. This association occurs when the endpoint is created. An endpoint 

45 creation implies a static association of the socket with the protocol, which will remain invariant. However, in a 
multiprotocol environment, as described in the above referenced application, which facilitates heterogeneous 
connectivity, a transport endpoint may need to be bound to any of several connectivity, a transport endpoint 
may need to be bound to any of several available protocols after the creation of the endpoint. Therefore, if 
sockets are to be used in such an environment, a new socket structure which allows dynamic association of 

so the socket with the protocol must be devised. The present invention teaches such a socket structure. 

Summary of the Invention 

The present invention provides a system and a method for communicating between nodes in a computer 
55 network in which a plurality of protocols are useable by network nodes, the method comprising the steps of 
creating communication endpoint objects defining communication parameters for respective network nodes, 
the objects having information about the plurality of protocols which are useable by said node for inter-node 
communication; and at the time communication is requested between said nodes, establishing a connection 
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between said nodes using a selected one of the plurality of protocols. 

The present invention thereby facilitates late binding of an endpoint to a transport protocol in a distributed 
environment enabling a more dynamic association between protocol and endpoint. 

Preferably, the invention allows native access to a protocol by an application. It is also preferred that the 
5 invention provides the necessary information for non-native connections to a protocol. 

The invention provides, in a preferred embodiment, a new socket structure which moves the decision on 
which protocol to use to the time that the connection is actually made between nodes in the network. In a mul- 
tiprotocol network, the new socket structure can be created for every endpoint For all of the protocols which 
could potentially be used to send or receive data a request is made to create a protocol control block at the 
10 time the new socket is created. A selection process determines which of the protocols could potentially be used 
by a given endpoint The new socket for the endpoint then contains information on each of the selected pro- 
tocols. At the time a connection is established, any of the selected protocols could be used. Native or non- 
native connections can be made. The choice of which protocol to use or the order of protocol preference can 
be based on user preferences through configuration, the local cache, or information from the named service 
15 unit 

Brief Description of the Drawings 

The invention will now be described in more detail, by way of example, with reference to the accompanying 
20 drawings in which: 

FIG. 1 is a diagram of two single protocol networks coupled together through a multiprotocol transport net- 
work. 

FIG. 2 is a block diagram of the transport interface used according to an embodiment of the present in- 
vention. 

25 FIG. 3 is a diagram of a conventional socket control block. 

FIG. 4 is a diagram of the socket control block according to an embodiment of the present invention. 

FIG. 5 is a flow diagram of the creation of a socket according to an embodiment of the present invention. 

FIG. 6 is a flow diagram of establishing a connection in a multiprotocol transport network environment 
using a multiprotocol socket according to the invention. 
30 FIG. 7 is a representation of a computer system including system unit, keyboard, mouse and display. 

FIG. 8 is a block diagram of the computer system components depicted in FIG. 7. 

Detailed Description of the Drawings 

35 The following description describes a socket based architecture. However, the invention is not limited to 

sockets and could be applied to similar communication endpoint objects in other operating systems. 

Although the following description contains an adequate disclosure of conventional socket and network 
architecture to allow one skilled in the art to understand the present invention, the reader is referred to The 
Design and Implementation of the 4.3 BSD UNIX Operating System by S. J. Leffer et at, 1 989 which is hereby 

4o incorporated by reference, for a more complete understanding of operating system based on the Berkley ver- 
sion of UNIXTM. Such operating systems are well known. 

FIG. 1 shows three single protocol networks 10, 12, 14 which are interconnected through a gateway 59 
built according to the principles of the present invention. With the growth of network distributed environments, 
it is not uncommon to see networks using four or five different protocols, such as TCP/IP, NetBIOS, SNA or 

45 AppieTALK. Since applications which run on one network will not often run with applications on the other, trans- 
port of data throughout the network is hindered. As discussed above, the Multiprotocol Transport Network 
(MPTN) 16 as taught in the above referenced application addresses these problems by defining an interface 
and a compensation mechanism to a set of transport services that provide connections across a plurality of 
transport protocols. By providing a transport boundary between the networks and the applications resident 

50 on systems, MPTN provides a common transport interface so that messages from the applications can be 
transported over any protocol in the network. 

As shown in FIG. 1 . hosts 20 and 22 are coupled to the multiprotocol transport network 16. While the MPTN 
1 6 appears as though it is a single logical network having a single protocol, host 20 is coupled to a first network 
10 which communicates via protocol X, e.g., TCP/IP, and host 22 is coupled to a second network 12 which 

5 communicates via protocol Y, e.g., NetBIOS. 

Application program A 24 resident in one of the hosts 20 coupled to the MPTN network 16 wishes to com- 
municate to application B 26 resident in another host 22 also coupled to the network 16. Upon application A's 
call to the socket layer 27, a socket is created by the socket layer 27 defining application A as an endpoint. 
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Sockets contain information about their type, the supporting protocols used n the transport tajjjr28 ■ndfltar 
state Aconnection request goes through the transport layer 28. the network layer 29 and the network interface 
fayer 'sOvTch the necessary control and data information before the message is sent out on the netwo* 
i Compensattonforthe differences between protocol y and X is carried out by the transport layer as taught 

^ ^ 6 TdXTh^rS n es in memory at a computer system which is coupied to the multiprotocol 
transport network in greater detail. The socket programming interface 60 and common transport semantics 
£££££ t thelocket iayer and separate the applications 64. 66. 68 from the service ^dnvers 70 72 
74. Three *pes of applications 64. 66. 68 are shown in the application layer. Tb ; ufl,ze the sock :et stmcture^of 
the present invention. NetBIOS applications would be rewritten to the socket API to become the NetBK>S sock- 
et JSEZ 1 66 The standard local IPC socket application 64 and TCP/IP applications 68 are already wntten 
to a standardized socket programming interface and so would require an min.mum of revisions. The ^ommon 
SansSrt semantics 62. indude the socket control blocks, which will be described n greater dete. below An 
Sate between the s^ket layer and the transport layer is comprised by the local ser \'^^^®J.^ ^® 
NeffilOS service driver 72 and the .Net service driver 74 which correspond to the appl.cat.ons m *"pphcat»n 
layer The service drivers are used to emulate the common transport semantics for the transport protocol driv- 
ers in the transport layer. In the present invention, they may also contain the compensatmg ^ 
in the above referenced application which converts a message intended tors f,rs protocol by %!fg£% 
to a second protocol supported by the network. The transport layer includes the NetBIOS 76 and TCP/IP 78 
protocol drivers which cause the application message to conform to the protocol format There , iji » nc ^.re- 
sponding local IPC module as it describes a local protocol whose messages are not placed or , the "e^or£ 
SS network and network interface layers are not pictured, the latter would indude , de 
hardware which couples the computer system to the network. e.g. a token ring or ethernet dnven the former 
might include drivers written to the well known NDIS interface. 

A socket is the object in the Berkeley version of UNIX(TM) from which messages are sent and received 
Sockets are created within a communication domain asf lies are created within a file system. AcommunK^ton 
domain summarizes the sets of protocols, the naming conventions, the hardware wh.ch may be a part.cu lar 
network and may use an address which refers to the communication domain. The internet domain , specif .ed 
Sy the address family AF_.NET; the NetBIOS domain Is referenced by the address family f^ETBIOS' Acon- 
nection Is a means by which the identity of the sending socket Is not required to be sent with each packet of 
data The Identity of each communication endpoint Is exchanged prior to any transm.ssion of data and is main- 
tained at the transmitting and receiving nodes, so that the distributed applications at each end can request 
the socket information at any time. , , . 

When an application creates a socket endpoint for a certain protocol and the protocol chosen by the trans- 
port network matches that protocol, native networking has occurred. For example the INet protocd I « used 
to support the INet address family and NetBIOS supports the NetBIOS address family. On the other hand 
when the transport protocol does not match the socket endpoint of an application it is termed non-natrve net- 
ting Using the present invention, however, the application is unaware that a different transport protocol 
is being used to connect with other nodes in the network. 

In the present invention, the socket interface is used to connect between rephcas of a distnbuted appli- 
cation or the client and server portions of a client/server application using a variety of transport P™tocols_ The 
application can select the transport protocol or request that the socket layer determ.ne the protocol. Wrth the 
non-native networking feature of the present invention, applications written to communicate wrth one anot er 
using one protocol can choose to communicate on another transport protocol which m.ght be opUmzed for the 
network environment For example, an application written for TCP/IP could commumcate using the NetBIOS 
protocol over the network.giving the distributed application a significant performance gam. 

A conventional socket control block is depicted in FIG. 3. a socket control block 100 conta.ns information 
about the socket, including send and receive data queues, their type, the supporting protocol, their state and 
socket identifier. The socket control block 100 includes a protocol switch table pointer 104 and a protocol con- 
trol block pointer 106. The pointers are used to locate the protocol switch table (not pictured) and the protocol 
control block 102 respectively. The protocol switch table contains protocol related information, such as entry 
points to protocol, characteristics of the protocol, certain aspects of its operation which are Pertinent to the 
operation of the socket and so forth. The socket layer interacts with a protocol in the transport layer through 
the protocol switch table. The user request routine PR.USRREQ is the interface between a protocol and the 
socket The protocol control block contains protocol specific information which is used by the protocol and is 

dependent upon the protocol. 

A socket control block according to the present invention is shown in FIG. 4. Here, the socket control block 
110 is shown broken into two sections, the main socket control block which is largely identical to the conven- 
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tional socket control block above and the MPTN extension 112 which contains many of the features necessary 
for the present invention. Both are linked together by a multiprotocol transport network extension 113. Each 
of the protocols which could be potentially used to send or receive data is sent a request to create a protocol 
control block 120, 122 at the time the new socket is created. After a selection procedure, the new socket then 
contains information regarding each selected protocol, the protocol switch table pointer 114, 118, the protocol 
control block pointer 116, 119, and a pointer to a interface address if applicable for the particular protocol (not 
pictured). As above, the protocol switch table pointer refers to a respective protocol switch table which defines 
various entry points for that protocol. Also, the protocol control blocks 120, 122 contain protocol specific in- 
formation. 

At the time of socket creation, no connection is made to any particular protocol to the application endpoint 
Connection implies an association of the connection-requestor socket of the requesting application to another 
connection-acceptor socket. It can be viewed as a communication wire running between the two sockets that 
are "connected", potentially in two different continents, providing the ability for both of them to send and receive 
messages. There is no difference between a transmitting socket and a receiving socket for the present inven- 
tion. After a connection, each can send or receive data. 

The decision on which protocol to use is delayed until the time that the connection is actually made. At 
the time of establishing a connection, any of the network interfaces in a protocol could be used. The order in 
which the pointers which refer to the protocols and network interfaces is based on user preference, information 
from the named service unit or the capability of the protocol the socket extension 112 which contains the poin- 
ters 114, 116, 118 and 119, also includes state information on the socket and the multiprotocol transport net- 
work. The socket extension 112 is used by the socket layer to manage the socket and MPTN states. From the 
list of available protocols, the socket layer picks those protocols that support the requested socket domain and. 
the type of communication (datagrams, streams, etc), as described in the flow diagram for socket creation de- 
scribed below. 

A sample socket control block structure is given in the code below: 
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/* socketva.h 

* Kernel structure per socket. 

* Contains send and receive buffer queues. 

* handle on protocol and pointer to protocol 

* private data, error information and MPTN extensions. 

* The first part of this structure ( upto the so_mptn field ) is identical 

* to the BSD4.3 socket control block. 
*/ 

struct socket ( 

short so.type; 
short sorptions: 
short sojinaer; 
short so.state; 
caddr_t solpcb; 

struct protosw far *so_proto; 



/* generic type, see socket. h */ 
/* from socket call, see socket. h */ 
/* time to linger while closing */ 
/* internal state flags SS,\ below */ 
/* protocol control block */ 
/* protocol handle */ 



Variables for connection queue inq. 

Socket where accepts occur is so_head in all subsidiary sockets. 

If so.head is 0. socket is not related to an accept. 

For head socket so_qO queues partially completed connections, 

while so_q is a queue of connections ready to be accepted. 

If a connection is aborted and it has so_head set. then 

it has to be pulled out of either so oO or so_q. 

We allow connections to queue up based on current queue lengths 

and linit on number of queued connections for this socket. 



/ * 
*/ 



struct socket far *so_head; 
struct socket far *so_qO; 
struct socket far *so_q: 
short so.qOlen: 
short so.qlen; 
short so aliitit; 
short so.tineo: 
u_sbort so.error; 
short solpgrp; 
u_long so_oobmark; 
Variables for socket buffering. 



/* back pointer to accept socket */ 
/* queue of partial connections */ 
/* queue of i neon inq connections */ 
/* partials on so_qO */ 
/* number of connections on so_q 
/* max number queued connections 
/* connection timeout */ 
/* error affecting connection */ 
/* parp for signals */ 
/* cnars to oob mark */ 



*/ 
*/ 



struct 



sockbuf 

ujong 

u_long 

u_long 

u_long 

u_long 

struct 

struct 

short 

short 



{ 

Sb_CC; 
sb_hiwat; 
sb_nbcnt ; 
sb_nbmax; 
sbjowat; 
mbuf far *sb_mb; 
proc far *sb_sel; 
sb_timeo; /* 



sbjlags: 



/* actual chars in buffer */ 
/* max actual char count */ 
/* chars of mbufs used */ 
/* max chars of mbufs to use */ 
/* low water mark (not used yet) */ 
/* the mbuf chain */ 
/* process selecting read/ write */ 
tiieout (not used yet) */ 
/* flags, see below V 



40 



45 



50 



55 



} so_rcv. so_snd; 
/* MPTN SOCKET EXTENSION */ 
struct m_esock far * sojnptn; 



define SB MAX 
define SB~L0CK 
define SB'MANT 
ttdefine SB'HAIT 
tdefine SB SEL 
#def ine SB~C0LL 



<(u long)(64*1024D) 
OkOI 
0x02 
0x04 
0x08 
0x10 



/* socket MFTN extensions V 

/* max chars in sockbuf */ 
/* lock on data queue (so_rcv only) */ 
/* someone is waiting to lock */ 
/* someone is waiting for data/space */ 
/* buffer is selected */ 
/* collision selecting */ 



/* Socket extensions for MPTN 

* The socket control block points to this structure which contains 

* all the NPTN related socket extensions. 

* Since n_esock. the MPTN extensions to sockets, is contained in one 

* mbuf, we could use the rest of mbuf space to accommodate the peb 

* pointers. 
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/* defines the structure for storing additional pointers. 

* used in n esock. 

* The structure u_addr defines the address fornat.lt is defined in nptndef.h. 

* The structure n.info defines the user specified connection characteristics 

* and is defined in nptndef.h. 

* The structure bnlst defines the user configured protocol preference list 

* and is defined in nptndef.h. 



*/ 

struct n_sopcb { 

struct protosv far * so proto; 

caddr_t so_pcb; 

struct i»_addr far * sojmsap; 

>: 



/* 
/* 



protocol switch ptr */ 
pointer to the PCB */ 
the network interface 
the PCB refers to */ 



that 



struct n_conn_stat { 
char type; 

char index; 



caddr_t ftnan; 



/* OST BNSAP.FOUND.USE PREF.LIST.CACHE. 
* GW.HEXT.HQP. GW.BNSAP */ 
/* current network... as an index in to the 

* pref. list as the case is. 
*/ 

/* destination name.. for ABM case. Gateway 

* cases, it is dst_b_nam. 

* In the native caie or cache case. contains 

* the dest A-addr 
*/ 



25 



struct bnlst far *prflst: 



/* pointer to the pref list */ 
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SO 



* so_info; 

* so_cinfo; 



struct n esock { 
int <» so_upcall ) () 
struct socket far * so_relay 

struct n_info far 

struct njnfo far 

short so_doitain: 

struct n_addr far 

struct n_addr far 

struct ibuf far * 

struct nbnf far * 

struct socket far 



/* user upcall address */ 



relay socket pointer: for gateway only */ 
/* connection chars given at n create OV 



* so_lanam; 

* so_panam; 
so^ctdata; 
so_expdat; 

* so_next: 



/* conn. char of a connection */ 
/* user specified domain */ 
/* local user naete */ 
/* peer user name */ 
/* connection/teritination data */ 
/* expedited data */ 

/* linked list of nonnative scbs.to search 

* for user-names*/ 

/* nptn flags having the following defs*/ 
/* to maintain mptn_connect 6tatus */ 
/* number of pcbs currently in sopcbl I */ 
/* pcb state:cit position corresponds to 

* pcb array; 0->in-use; else not-in-use*/ 
m.sopcb sopcb IMPTNJfAXPCBl;/* array of n sopcb structures */ 



unsigned so_nptn_flag : 
struct n_conn_stat conn_stat; 
short so_pcbniin ; 
long sojxrbstat; 



struct 



55 



tdefine MPTN_NONNATIVE 0x01 

tdefine MPTN NATIVE 0x02 

tdefine MPTN_SO_BIHD 0x04 

fdefine MPTN SO UNBIND 0x08 

Idefine HPTNlSOCONN 0x10 

tdefine MPTN_SO_NQH0RB_C0NN 0x20 

fdefine MPTN SO LISTEN 0x40 
Idefine MPTN„SOlCON_HEAD_WAIT 0x80 

#define MPTN_SO_CON READ RCVD 0x0)00 
tdefine MPTN SO CON HEADSENT 0x0200 
tdefine MPTN S0_C0N~ESTABL1SHED 0x0400 
idefine MPTN_SO_CLOSED 0x0800 
tdefine MPTNSO_BCAST_RCV 0x1000 

tdefine MPTN_S0_ I N_ADDR_ANY 0x2000 



/* indicates nonnative connection */ 

/* indicates native connection */ 

/* sock nptn state~>addr bound */ 

/* sock siptn state=>addr not bound*/ 

/* sock nptn state°>connect req is made*/ 

/* ->there will be no more conn, re-try 

* over other net works /protocols*/ 
/* init state of a passive sock V 

/* native con set up.. waiting for MPTN 

* connect header */ 

/* passive node. . .wptn con rcvd. .*/ 
/* Active node...mptn con sent ..*/ 
/* Connection established ...*/ 
/* local socket close issued */ 
/* the socket is enabled to rev 

* broadcast dgins.*/ 

/* the socket is bound to in_addr_any */ 
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* Socket state bits. 
*/ 

fttefine SSJfOFDREP 
Mefine SS ISCQNHECTBD 
idefine SS'ISCONNBCTING 
fidefine SS ISDI9CQNHBCTIKG 
idefine SS C&NTSENDMORE 
*def ine SS CWTTRCVM0R8 
define SSJICVATMARK 

*define SS.PRIV 
Mefine SSJIBIO 
fciefine SS.ASVNC 

Idefine SS CANCEL 
fldefine SS~PUSHSKEN 



0x001 
0x002 
0x004 
0x008 
0x010 
0x020 
0x040 

0x080 
0x100 
0x200 

0x4000 
0x8000 



/* no file table ref any more */ 
/* socket connected to a peer */ 
/* in process of connectinq to peer */ 
/* in process of disconnecting V 
/* can't send more data to peer */ 
/* can't receive »ore data from peer */ 
/* at nark on input */ 



/* privileged for broadcast. 
/* non-blocking ops */ 
/* async i/o notify */ 

/* cancel call */ 
/* seen push */ 



raw... V 



/* Rest of the info is the sane as in the BSD4.3 socketva.h */ 
Copyright. IBM Corp. 1993 

Conventional socket creation starts with a call to the socket API. A domain table is searched for the address 
family, the type and protocol which is desired by the application. If a match is found the protocol switch table 
entry is set in the socket control block. Next the user requests entry and the selected protocol is called to 
create of the protocol control block. If a match is not found in the domain table for the address family, type and 
protocol desired by the application, an error is returned to the application. 

FIG. 5 depicts the process of creating a socket according to the present invention. The process begins 
with a socket creation request 150 from an application to the socket API, the application wishes to send or 
receive data across the network. The command to the socket API for the request takes the form of socket=<AF f 
*, type, proto). "AF" refers to the address family and communication domain; "type" refers to one of the socket 
types defined in a system header file. The "proto" or protocol parameter is used to indicate that a specific pro- 
tocol is to be used. A test is performed in step 152 to determine if "proto" is specified. If so, the normal socket 
creation process in step 154 is carried out and the process ends, step 155. 

If "proto" is not specified, the process continues to create a multiprotocol socket. Each protocol is associ- 
ated with a protocol switch table. For each protocol switch table, step 155, tests are performed whether the 
type and address family of the requesting endpoint, steps 158 and 160, are matched by the protocol. In step 
158 the test for "type" match is performed. If the test fails, the process returns for the next protocol switch 
table, step. 156. If the test succeeds, the test for address family match is performed in step 160. Both the "type" 
and "family" are represented as integers. By matching, the socket layer compares the 'type' and "address fam- 
ily" field supplied by the user and the 'type' and "address family" fields in the protocol. If a match is found for 
both type and address family, the protocol is selected as a candidate protocol and set in the socket extension 
with pointers to the protocol switch table and protocol control block, step 162. If there is no match, the process 
determines whether the address family is supported non-natively in the network, step 164. If the protocol is 
supported, step 166, the protocol is selected as a candidate protocol and set in the socket extension with poin- 
ters to the protocol switch table and protocol control block, step 162. If the protocol is not supported, in step 
166, a test is performed to determine whether it is the last protocol switch table. If not, the process returns to 
step 1 56. If it is the last protocol switch table, the process ends, step 170. The protocol pointers can be reordered 
within the extension according to the application or user preference through the use of a configuration tool or 
according to information from the named server. 

In FIG. 6 t the process to establish a connection using the multiprotocol socket is described. The process 
begins in step 200 where the socket layer tries connecting to a specified destination using the first protocol 
from the list of protocols in the socket extension. The choice of which of the protocols to try first can be based 
on the configuration of user specified preference order of protocols. If the connection succeeds, step 222, the 
process ends in step 223. If not, the next protocol is used to try to establish a connection in step 224. Tests 
are performed determine whether a connection is made, step 226. If so, the process ends. If a connection is 
not made, a test is performed to determine whether it is the last protocol in the socket extension. If not. the 
next protocol in the extension is tested, step 224. If all the protocols used when creating the socket have failed 
to provide the connection, the transport provider returns a notification of failure to the application, step 232. 

As mentioned previously, the invention finds use in a plurality of computers which are part of a network 
such as a Local Area Network or wide Area Network. Although the specific choice of computer in these net- 
works is limited only by performance and storage requirements, computers in the IBM PS/2 (TM) series of com- 
puters could be used in the present invention. For additional information on IBM's PS/2 series of computers, 
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the reader is referred to Technical Reference Manual Personal Systems/2 Model 50, 60 Systems IBM Corpor- 
ation, Part No. 68X2224 Order Number 568X-2224 and Technical Reference Manual Personal Systems/2 
(Model 80) IBM Corporation Part No. 68X 2256 Order Number S68X-2254. One operating system which an 
IBM PS/2 personal computer may run is IBM's OS/2 2.0 (TM). For more information on the IBM OS/2 2.0 Op- 
5 erating System, the reader is referred to OS/2 2.0 Technical Library. Programming guide Vol. 1. 2. 3 Version 
2,00 Order Nos. 10G6261, 10G6495, 10G6494. In the alternative, the computer system might be in the IBM 
RISC System/6000 (TM) line of computers which run on the AIX (TM) operating system. The various models 
of the RISC System/6000 are described in many publications of the IBM Corporation, for example, RISC Sys- 
tem/6000. 7073 and 7016 POWERstation and POWERserver Hardware Technical reference, Order No. SA23- 
10 2644-00. The AIX operating system is described in General Concepts and Procedure-AlX Version 3 for RISC 
System/6000 Order No. SC23-2202-00 as well as other publications of the IBM Corporation. In lieu of the cited 
references, the reader is offered the following general description of a computer system which could be utilized 
to practice the present invention. 

In FIG. 7 f a computer 310, comprising a system unit 311 , a keyboard 312, a mouse 313 and a display 314 
15 are depicted. The screen 316 of display device 314 is used to present the visual changes to the data object. 
The graphical user interface supported by the operating system allows the user to use a point and shoot method 
of input by moving the pointer 315 to an icon representing a data object at a particular location on the screen 
316 and press one of the mouse buttons to perform a user command or selection. 

FIG. 8 shows a block diagram of the components of the computer shown in FIG. 7. The system unit 11 
20 includes a system bus or plurality of system buses 21 to which various components are coupled and by which 
communication between the various components is accomplished. The microprocessor 322 is connected to 
the system bus 321 and is supported by read only memory (ROM) 323 and random access memory (RAM) 
324 also connected to system bus 321. A microprocessor in the IBM multimedia PS/2 series of computers is 
one of the Intel family of microprocessors including the 386 or 486 microprocessors. However, other micropro- 
25 cessors included, but not limited to, Motorola's family of microprocessors such as the 68000, 68020 or the 
: 68030 microprocessors and various Reduced Instruction Set Computer (RISC) microprocessors manufactured 
by IBM, Hewlett Packard, Sun, Intel, Motorola and others may be used in the specific computer. 

The ROM 323 contains among other code the Basic Input-Output system (BIOS) which controls basic hard- 
ware operations such as the interaction and the disk drives and the keyboard. The RAM 324 is the main memory 
30 into which the operating system, transport providers and application programs are loaded. The memory man- 
agement chip 325 is connected to the system bus 321 and controls direct memory access operations including, 
passing data between the RAM 324 and hard disk drive 326 and floppy disk drive 327. The CD ROM 332 is 
also coupled to the system bus 321 . 

Also connected to the system bus 321 are various I/O controllers: The keyboard controller 328, the mouse 
35 controller 329, the video controller 330, and the audio controller 331 which control their respective hardware, 
the keyboard 312, the mouse 313, the display 314 and the speaker 315. Also coupled to the system bus 321 
is the digital signal processor 333 which corrects the sound produced by the speaker 315 and is preferably 
incorporated into the audio controller 331. An I/O controller 340 such as a Token Ring Adapter enables com- 
munication over a network 342 to other similarly configured data processing systems. 
40 While the invention has been described with respect to particular embodiments above, it will be understood 

by those skilled in the art that modifications may be made without departing from the spirit and scope of the 
present invention. The preceding description has described the principles of the present invention in terms of 
a particular communications endpoint object, a socket, in the socket layer between the application layer and 
transport layer. The principles of the invention could be extended to provide similarly configured communica- 
45 tion endpoint objects in other layers. For example, an object in the network interface layer could be used to 
monitor a plurality of underlaying MAC drivers to that data could be sent or received over a plurality of MAC 
protocols to different types of networks. These embodiments are for purposes of example and illustration only 
and are not to be taken to limit the scope of the invention narrower than the scope of the appended claims. 

so 

Claims 

1. A method for communicating between nodes in a computer network in which a plurality of protocols are 
useable by network nodes, the method comprising the steps of: 
55 creating communication endpoint objects defining communication parameters for respective net- 

work nodes, the objects having information about the plurality of protocols which are useable by said node 
for inter-node communication; and 

at the time communication is requested between said nodes, establishing a connection between 
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said nodes using a selected one of the plurality of protocols. 

A method according to claim 1, wherein the selected protocol is chosen based on user preferences. 

A method according to claim 1, wherein the selected protocol is chosen based on a capability of the se- 
lected protocol. 

A method according to any one of the preceding claims, wherein the creating step comprises the steps 
of: 

requesting information of each of the plurality of protocols; 

selecting a set of protocols from the plurality of protocols, which selected protocols are useable by 

the respective nodes; 

building a protocol control block for each of the selected protocols; and, 

inserting a pointer in the communication endpoint object for each protocol control block of a se- 
lected protocol. 

A method according to claim 4, wherein the order in which the pointers are inserted is based on user pref- 
erence. 

A method according to claim 4 wherein the selecting step comprises the steps of: 

determining whether there is a match for a first protocol for a first set of protocol parameters, the 
first protocol corresponding to a first pointer in the socket; and, 

responsive to finding no match for the first protocol, determining whether the first protocol is sup- 
ported non-natively in the network. 

A system for communicating between nodes in a computer network in which a plurality of protocols are 
useable by network nodes, the system comprising: 

means for creating communication endpoint objects defining communication parameters for re- 
spective network nodes, which objects have information about the plurality of protocols useable by re- 
spective computer systems each coupled to one or more nodes in the network; and, 

means for establishing a connection between a first and a second computer system using a se- 
lected one of the plurality of protocols at the time communication is requested between nodes on the dif- 
ferent systems. 

A system according to claim 7, which further comprises: 

means for selecting a set of protocols from said plurality of protocols; 

means for requesting information from each of the plurality of protocols; 

means for building a protocol control block for each of the selected protocols; and, 

means for inserting a pointer in the communication endpoint object for each protocol control block 
for a selected protocol. 

A system according to claim 8, which further comprises: 

means for determining whether there is a match for a first protocol for a first set of protocol para- 
meters, the first protocol corresponding to a first pointer in the socket; and, 

means for determining, responsive to finding no match for the first protocol, whether the first pro- 
tocol is supported non-natively in the network. 
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(54) Socket structure for concurrent multiple protocol access. 



(57) In a multiprotocol environment, a new socket 
structure is provided which moves the decision 
on which protocol to use until the time that the 
connection is actually made between nodes in 
the network. The new socket structure is 
created for every endpoint All the protocols 
which could potentially be used to send or 
receive data is sent a request to create a pro- 
tocol control block at the time the new socket is 
created. A selection process determines which 
of the protocols could be used by the endpoint. 
The new socket then contains information on 
each selected protocol. At the time a connec- 
tion is established, any of the selected protocols 
could be used. The choice of which protocol to 
use can be based on user preferences, which 
protocols are available, the name of the service 
unit 
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